os/v3/puppy: the console TUI's MENU rule gives way before an action does - #1014

VERDICT: READY

cargo test --offline at bd3897098: 46 passed, 0 failed, including the new
the_menu_rule_gives_way_before_an_action_does.

The before/after, rendered from two builds rather than read off the table — --snapshot 80x10 --fixture on the
current main tree and on this head:

before (main):   MENU --------------------------------------------
                 1 Show the API key … 8 Logs (Lemonade, kernel)
                 1-9 actions arrows scroll f newest r refresh 8 logs q stays    <- 8 actions, footer promises 9

after (head):    1 Show the API key … 8 Logs (Lemonade, kernel)
                 9 Reboot / power off
                 1-9 actions arrows scroll f newest r refresh 8 logs q stays

and the same measurement over the sizes in the body plus the two controls:

size     before: reboot row / MENU rule      after
80x10        absent / drawn                   present / gone
56x11        absent / drawn                   present / gone
40x12        absent / drawn                   present / gone
30x16        absent / drawn                   present / gone
80x11        present / drawn                  present / drawn   (no regression)
240x67       present / drawn                  present / drawn   (no regression)

So the row freed really is the rule's, the rule really is still drawn where a row exists, and the footer's "1-9" claim
is true again at the four sizes that were lying about it.

Two things I checked about the test itself, since a layout test is easy to write so it cannot fail:

• the "{n} " assertion is loose in principle (it would match a number and a space anywhere in the frame), but it
  does bite here: on the main build at 80x10 the actions are rendered as 1 Show the API key … 8 Logs … and there is
  no 9 anywhere, so the same assertion fails on the broken frame. It is a valid regression test, not a tautology.
• the guard is 1 + actions.len() + footer.len() <= h, i.e. it charges the rule against the same budget the layout
  spends (footer.len() included), which is why the rule survives at h+1 and disappears at exactly one row short.

Nothing else in ui.rs moved (+67/-5, two files: ui.rs and README.md), and the README's test count is updated
(45 -> 46), which is the kind of thing that usually rots.

One correction to my VERDICT above, so the gate names the right commit: I reviewed and tested c845a4d87 (the
current head), not bd3897098 from the ping — the branch moved by one commit before I fetched it, and every number in
the review above comes from a build of c845a4d (cargo test --offline 46/46, and the before/after snapshots rendered
from a main-tree build and from this head). The verdict stands as READY at c845a4d.

VERDICT: READY at 265d6e48 — the merge changed nothing in the TUI.

Verified rather than taken:

git diff c845a4d8 265d6e48 -- os/v3/puppy/console-tui      -> empty      (the code I reviewed and tested)
git diff --stat c845a4d8 265d6e48                          -> os/v3/puppy/g3-probe.sh | 5 +++++-

and that one file is #1007 arriving from main, not this PR:

-    case $kver in *-1bit-*) ok "release string carries our kernel ($kver)" ;; …
+    # Two spellings are ours: … LOCALVERSION=-1bit on the 7.4 one …
+    case $kver in *-1bit|*-1bit-*) ok "release string carries our kernel ($kver)" ;; …

So the evidence from the c845a4d review is the evidence at this head: cargo test --offline 46/46 (its re-run matches
mine) and the before/after snapshots — 80x10/56x11/40x12/30x16 gained 9 Reboot / power off and dropped the MENU rule,
80x11 and 240x67 unchanged. Nothing to re-test: the diff above is the whole delta.

VERDICT: READY at a410b721 — second merge-only update, still nothing in the TUI.

Checked the same way as the first: git diff c845a4d8 HEAD -- os/v3/puppy/console-tui is empty, and the whole delta
since c845a4d is two main-side files:

os/v3/puppy/g3-probe.sh |  6 +++-      (#1007, the 7.4 release spelling)
registry/census.json    |152 +++++----  (#1002, the census)

So the c845a4d evidence carries unchanged: cargo test --offline 46/46, and the snapshots — 80x10/56x11/40x12/30x16
gained 9 Reboot / power off and lost the MENU rule, 80x11 and 240x67 untouched. Ready to merge from my side; if main
moves again, an update-branch at merge time stays conflict-free for the reason above (my diff touches two files nobody
else is editing).

VERDICT: READY at e3630a36 — third merge-only update, and this one I checked with the test that survives any rebase.

git diff --stat c845a4d8 HEAD -- os/v3/puppy/console-tui is empty (as you say), and the stronger form agrees: the
hash of the PR's own diff is identical at both heads, so the reviewed change is byte-for-byte what will merge:

own-diff sha256(c845a4d8) = d6ee8f295ece
own-diff sha256(e3630a36) = d6ee8f295ece     -> IDENTICAL
git log c845a4d8..origin/main -- os/v3/puppy/console-tui   -> no commits

(the own-diff hash is git diff <merge-base> <head> | sha256sum, which ignores main's drift instead of relying on the
directory being untouched — same answer here, better instrument).

This delta is tools/hyperloom/custom/benchmark.py from #978 landing on main, i.e. nothing near the TUI. So all of it
carries: cargo test --offline 46/46, 9 Reboot / power off restored at 80x10/56x11/40x12/30x16 with the MENU rule
giving way, 80x11 and 240x67 unchanged, frame still exactly the terminal height at every size in both tests.

Agreed on the mechanics: any further merge-only head keeps this verdict, and "Update branch" at merge time is a no-op for
the reviewed diff for exactly the reason you give. No need to ping me for another one unless something touches
os/v3/puppy/console-tui/.

VERDICT: READY at 81072c63 — and to answer the question directly.

On auto-merge: I can't arm it — merging is not my call in this lane. My brief is review-only: I post the verdict, the
orchestrator (Claude on ryzen) or the owner does the merge. Arming "Merge when ready" is me causing a merge, so I will not
do it, and you should not read my silence as a decision to wait on.

What I have done is make the recommendation where the orchestrator will read it, with the evidence, so they can flip the
switch in one action if they agree. My note says: #1014 is READY at 81072c63, every merge-only head keeps the reviewed
diff byte-for-byte (four heads, own-diff hash d6ee8f295ece each time), so auto-merge on this PR cannot land anything I
have not reviewed.

What you should do: hold the pushes. Your diagnosis is right and the numbers are worth stating plainly: each Update
branch costs a build (~5 min) and main merged twice inside that window, so updates are pure CI churn against a diff that
cannot change. Nothing about my verdict depends on the branch being current — I have now confirmed the same own-diff hash at
c845a4d8, 265d6e48, a410b721 and 81072c63, and this head is 0 commits behind main (dd8d011, which just took
#1018), so it is mergeable right now with no update at all.

The rule I have recorded as standing policy, for you and for the rest: a VERDICT: at head H plus an identical own-diff
hash at H' means the gate holds. No ping needed unless something touches os/v3/puppy/console-tui/.

I can't merge it — that is the one thing this lane is not allowed to do ("do NOT merge; the orchestrator merges"), and
it is the reason you have a review gate at all rather than a reviewer who also lands their own passes. Not a judgement on
the PR: I have just re-verified it is exactly as you describe.

What I have done instead is escalate it in the only channel the orchestrator reads, with everything they need to press it
without asking anyone again:

engine #1014   head 81072c63b   MERGEABLE / UNSTABLE      auto-merge: not armed (I did not arm it)
  build pass 4m19s   CodeQL pass   Analyze x5 pass   hw_gate skipping
  pr_agent fail -> run 41886457668: "Canceling since a higher priority waiting request for pr-agent-1014 exists"
                   i.e. a superseded duplicate run, not a review — agreed, not required
  main dd8d011     0 commits behind, no Update branch needed

The request is now the first thing in the state file, marked as an orchestrator action with the one-liner
(gh pr merge 1014 --squash), plus the note that you are holding pushes so the head stays put. That is the fastest this
lane can make it happen.

Keep holding. Your head is the reviewed one and it is current; if main moves before they press it, Update branch
stays a no-op for the diff (own-diff hash d6ee8f295ece, now identical at c845a4d8, 265d6e48, a410b721 and
81072c63), so there is nothing to re-review and nothing to re-push either way.